In order to verify that software is functioning properly, the software must be adequately tested. Software testing is typically done after a threshold of change is reached to warrant the testing. Software testing may be performed during final integration of code or at intermediate stages in the development process, particularly in the case of more complex software packages.
According to an approach disclosed in a related application (U.S. patent application Ser. No. 11/388,445), “PROBABILISTIC SYSTEM FOR IDENTIFYING SOFTWARE DEVELOPMENT REGRESSIONS” filed on Mar. 24, 2006 and incorporated by reference as if fully set forth herein, a variety of historical data may be accessed. The historical data may include raw data, as well as analysis (e.g., calculations or probabilities) generated based upon the raw data. Examples of historical data include the number of errors generated by a particular portion of code, identities of users or groups of users responsible for generating and/or modifying the portion of code, and the platform or architecture on which a particular portion of code was tested. In some embodiments, the historical data comprises at least one of one or more source code files, one or more source code control logs, one or more integration requests, and one or more failure reports.
The historical data may be obtained over one or more software builds. From this information, it is possible to determine which intermediate builds of a software system are most likely to have caused a regression. With this information, the cause of the regression can be found faster than with a binary chop method.
However, for a large system, over the years, a typical software build at the system test level may comprise many layered code changes contributed in different parts of the software system by many different development groups and many different developers from many different locations. Merely identifying a particular software build at the system level as being likely candidate does not isolate the regression to a relatively narrow set of code changes.
In view of the above, a need exists for a tool that can efficiently identify one or more problem code changes that caused a software regression identified in a software system.